1. Field of the Invention
The present invention relates to simulation of a physical system such as an automobile, and more specifically relates to a computer implemented simulation system.
2. Description of Related Art
Early in the 20th century, the automobile was made of mechanical components including engine for power, accelerator, steering wheel, transmission, and suspension, but almost no electrical devices were used other than the engine spark plugs and the headlights.
However, since the 1970s, there has been a need to control engine efficiency as a result of air pollution and oil crises, and therefore at ECU is used for controlling the engine. Generally, the ECU has an input interface that performs A/D conversion of an input signal from a sensor for example, a logical operator (microcomputer) that processes the digital input signal in accordance with established logic, and an output interface that converts the processed results to an actuator operating signal.
Nowadays, modern automobiles contain not only mechanical components, but electronic components and software occupy a significant share, extending not only to engine and transmission control systems, antilock braking system (ABS), electronic stability control (ESC), and power steering, but even extending to windshield wiper control and security of monitoring systems and the like. The development costs for these components are said to be from 25 to 40% of the total cost, and account for 70% for a hybrid vehicle.
Incidentally, automobiles contain a power device such as an engine, power transferring device, driving device for steering or the like, braking device, and other mechanical members for other body systems (plant), and the operations of these plants are dynamically determined by programs of 30 to 70 or more electronic control units (ECU) based on sensor input (speed or the like) and input from humans (accelerator and the like).
An ECU basically controls the operation of each individual plant. For example, an engine control unit uses software to determine the amount and timing for fuel injection and ignition of the engine. For high-grade vehicles such as those provided with a “sport” mode, the amount of fuel injected can be either increased or decreased depending on the mode by using software. Furthermore, the rotational speed of the engine can be made to match the timing for shifting down by the automatically blipping (racing) the engine. In this case, the engine ECU and the transmission ECU must operate in a cooperative manner. With an integrated vehicle position stabilizing device (ESC: Electronic stability control) for preventing lateral slipping or the like of the vehicle, coordination with the braking device such as the brakes or the like is essential, and thus ECU software is complex. Note, this type of “intervention” function is primarily software, and can easily be cut.
In order to sufficiently achieve the function of the plant and to operate stably, tuning and testing of the operating parameters must be sufficiently performed in the process of designing and developing the ECU software. Tuning and testing is repeatedly performed after a prototype is made of an actual vehicle, but because of cost and timing constraints, there is strong demand for a method that virtually achieves a controller and plant in a calculating device prior to prototyping, and thus the operation can be quickly and accurately performed. This ECU simulation includes 4 types, namely: (1) Model-in-the-Loop Simulation (MILS) that logically expresses the operation of the controller using an expression format such as a state machine; (2) Software-in-the-Loop Simulation (SILS) where some hardware control such as data precision is introduced to the logical operation; (3) Processor-in-the-Loop Simulation (PILS) and Virtual Hardware-in-the-Loop Simulation (V-HILS) where the software is completely packaged to emulate the ECU processor; and (4) Hardware-in-the-Loop Simulation where the ECU board is completely packaged and connected with a real-time plant simulation, used in this order to approach the prototype.
MILS and SILS are primarily used during the trial and error phase in order to achieve basic performance of the plant. However, the operation differs from the software that is actually included in the ECU, so use for product verification applications is not possible. On the other hand, V-HILS uses completed ECU software, and is extremely promising as a method for resolving unanticipated actions (bugs) that are discovered in the software, but there are no examples where an operation with reproducibility has been achieved. HILS is always performed in order to confirm the final behavior of the completed ECU board, but reproducibility is not insured even if a failure is discovered and therefore cannot be used for the purpose of debugging.
The reason that the operation cannot be reproduced using HILS is not because the configuration of HILS is incomplete, but rather because all of the ECU's are mutually connected together by a network such as CAN or the like. Generally, a network provides loose coupling between modules, so the order of data arrival will vary based on slight differences in timing of the module operation, and as a result the behavior of the entire system will vary. Therefore, even if the actual vehicle is prototyped, reproducibility of the operation cannot be expected. This is the same reason that debugging a parallel distributed system is extremely difficult.
With this type of HILS configuration, or in other words with a configuration where the ECU board and the plant simulator were loosely linked, operation consistency cannot be achieved even if each of the components are sped up. Achieving consistency in the order of communication is necessary in order to achieve reproducibility of the operation. V-HILS is expected to resolve this problem in particular.
According to traditional concepts, a typical V-HILS configuration includes a plurality of ECU emulators, a plurality of plant simulators, and a global scheduler that schedules all operations.
The ECU emulator includes a processor emulator and a peripheral emulator. On the other hand, the plant simulator includes a brake simulator and an engine simulator and the like.
At this time, the processor emulator operates using a relatively high resolution clock at 80 MHz for example. On the other hand, the plant simulator is a simulator of a physical mechanism, and therefore operates at a relatively low resolution of 10 kHz for example. Generally, a lower resolution can be simulated at high speed, so the plant simulator is often faster.
The plant simulator does not necessarily repeat calculations of values at processing step times that have a fixed length, and usually there is a need to suppress the effects of calculation differences and to have a variable step that is based on the timing of noncontiguous change points. Instruction signals are received from the controller in each step, and the internal state is output to each sensor. Note, the instruction signal is usually a pulse for expressing the on or off condition of a switch.
The peripheral emulator is mutually connected to the plant simulator and the processor emulator using the I/O interface of the ECU emulator. Typically, the operations can be suppressed at a resolution of approximately 10 MHz. This increases the speed of the plant simulator, but decreases the speed of the processor emulator. The peripheral emulator transmits a pulse signal to the plant simulator. Furthermore, the internal state from the plant simulator is read as quantized data.
The peripheral emulator receives a read write (R/W) request and transmits and receives data with the processor emulator, and sends interruptions (INT). In particular, with the function of a network such as a CAN (controller area network) that mutually connects between processors, transmission data is received from the processor (W) and communication between peripherals is performed through a bus, and when the data is received, an interrupt (INT) is sent to the processor, and the data received from the processor is read based on a request (R).
Looking from one side, the peripherals are the center of the system and mutually connected between the plant and the processor and between processors. If there is only sufficient time resolution to mutually distinguish the order of the signals that pass through the peripherals, the order can be properly reproduced for synergistic effects between the plant and the processor. If the time until the next signal determines the degree of precision (calculation rate and the like), a finer time resolution is favorable. In other words, the size of the data error is determined by the time resolution.
There is also a problem with overhead in addition to the problem with data error. In other words, with a method that provides a fixed synchronous interval, a more proper operation can be achieved if the synchronous interval is shortened, but conversely, the overhead required for synchronous processing will increase, so the time for all processes will increase.
An approach where the synchronous interval is fixed and reduced to the maximum limit cannot be a method for practically resolving both aspects of data error and overhead.
With V-HILS, the synchronous problem is critical, and when organized, the following three methods are conceivable:    (1) Time synchronization: With this method, the processor emulator executes the simulation while mutually communicating. There is a trade-off between execution speed and time precision, and there are quantization errors for time. Furthermore, as described above, with this method, the synchronous communication cost is higher between the processor emulators, so the practical resolution is not achieved.    (2) Optimistic event synchronization: With this method, each processor and emulator synchronizes with the other party by sending or receiving an event with time information. However, speculated simulation is executed while retaining the possibility of “flying”, so if the speculation causes out of order state, the processor and emulator must be rolled back appropriately. The cost of synchronization is smaller than with the time synchronization method, but the cost of successively recording the status in preparation of rollback is too high, and is not practical.    (3) Conservative event synchronization: With this method, each processor and emulator synchronizes with the other party by sending or receiving an event with time information. However, the simulation proceeds “conservatively” so a cause and effect relationship does not conflict, and therefore mutual events will be held, and a deadlock can occur. In order to avoid this type of deadlock, a special null message or the like is sent at high frequency in order to perform a time send, and thus the cost of avoidance is high.
As conventional technology for V-HILS, Japanese unexamined patent application 2007-11720 discloses that an issue to be resolved is to enable flexible variation of the configuration of a system simulator while accommodating systems with complex configurations, and that a system simulator includes 3 types, namely an instruction set simulator that simulates CPU operation, a bus simulator that simulates bus operation, and a peripheral simulator that simulates the peripheral operations, with an interface provided between each simulator that can reference and change the mutual state. However, this conventional technology does not suggest a technique of optimizing synchronization between peripherals and the CPU.
The present inventors developed a mechanism for conservative event synchronization and provided a simulation technique that used a peripheral scheduler as disclosed in the specification of UK patent application GB2486136A. With this technique, the peripheral scheduler begins parallel operation by the canceling (OFF) all peripheral emulator completion flags. Furthermore, the peripheral scheduler finds the peripheral emulator scheduled to face the earliest processing break, based on the timing of the processing break of each individual peripheral emulator that is set. This is referred to as peripheral P. If the time of that processing break is T, the peripheral scheduler proceeds with execution of each processor emulator and each plant simulator until the time reaches time T. Therefore, the peripheral scheduler waits for the peripheral P completion flag to be set. In response to setting of the peripheral P completion flag, the peripheral scheduler synchronizes the data between the peripherals P, the processor emulator, and the plant simulator.
However, recently there has been demand for simulation that more closely approaches the overall operation of the actual device such as simultaneously emulating a plurality of ECUs with a multicore host computer. The execution speed will vary for each of the hosts of a plurality of ECU, and therefore explicit synchronous processing is required there between. However communication that regularly interrupts is performed between the ECUs so synchronizing the plurality of ECU is not easy. The technique disclosed in the specification of Japanese patent application 2009-238954 is applicable only for a single ECU, so this technique cannot be applied without modification to simulations of systems that have a plurality of ECU.